Only make changes in setup-app and setup-cert if previous config does not already exist#29
Only make changes in setup-app and setup-cert if previous config does not already exist#29andrew-nowak wants to merge 1 commit intomainfrom
Conversation
andrew-nowak
force-pushed
the
an/setup-only-needed
branch
from
205b51d to
277d031
Compare
|
Hmm, not sure about this. We typically execute Does your use-case differ from this pattern? |
|
Interesting! I think there's often 3 parts of a local dev environment, some really long-term infra with very infrequent changes (eg. dev-nginx, unequivocally belongs to The example repo linked from that github blog post contains this comment in their setup script, which I think also agrees with my interpretation: https://github.com/github/scripts-to-rule-them-all/blob/2e68071ef33c5c6f0d525db00997cd333ff93e8d/script/setup#L3-L4 , though I appreciate I am possibly an outlier in the guardian in this |
|
Aha, yes, I see what you mean. Looking at the GitHub example, have we merged the role of the |
2 participants
What does this change?
As in the title: this means that we can include
setup-appin scripts, without devs constantly being prompted to auth for sudo when the config already exists and matches what would have been generated.How to test
Download, then setup an app.
If you've not already setup the app before, does the config get generated correctly?
Then if you run again, does
dev-nginxskip generating the config and restarting the nginx instance?How can we measure success?
Fewer sudo prompts :)
Have we considered potential risks?
--forceflags if users need config regeneration for some reason.opensslin setup-cert - I think this is sufficiently ubiquitous to be okay, but maybe there are setups where that's not available? Regardless, the script should fall back to current behaviour if it's not available, which I think should be fairly harmless.